home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 861 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.4 KB

  1. From: thp@cs.ucr.edu (Tom Payne)
  2. Message-ID: <4j6j2c$hev@galaxy.ucr.edu>
  3. X-Original-Date: 25 Mar 1996 16:53:32 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 26 Mar 96 04:44:15 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Return-Path: <daemon@meeker.UCAR.EDU>
  8. Newsgroups: comp.std.c++
  9. Subject: Re: Referencing pointers after delete
  10. Organization: University of California, Riverside
  11. References: <4iv8bd$5vh@galaxy.ucr.edu> <4ivagk$p3p@engnews1.Eng.Sun.COM>
  12. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMVd2QOEDnX0m9pzZAQG5DgF+JXSLtI7yBmXqerIUm5jTCzfsq1RKa+DI
  15.     WAd+U3pOEnpiEzxuSGZTV7uUh3PUvFWk
  16.     =98ad
  17.  
  18. Steve Clamage (clamage@Eng.Sun.COM) wrote:
  19. : In article 5vh@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
  20. : >Steve Clamage (clamage@Eng.Sun.COM) wrote:
  21. : >: You can't do anything useful in portable code with uninitialized
  22. : >: pointers, or pointers which point to objects which are no longer
  23. : >: available. The standard allows the implementation a great deal of
  24. : >: leeway in trying to help by identifying such invalid uses.
  25. : >
  26. : >.... just as for arithmetic exceptions, which also engender "undefined
  27. : >behavior."  But why the leeway to, say, reformat the disk, rather
  28. : >than specifying the normal practice, which is to invoke a signal
  29. : >handler, thereby, keeping the behavior defined?
  30. : Why should raising a signal be "normal practice"? Why not throwing an
  31. : exception? What about time-critical programs which would rather risk an
  32.  
  33. Throwing an exception would be incompatible (or of marginal compatibility)
  34. with C.  ( Too bad signal handlers can't throw exceptions ;-) )
  35.  
  36. : invalid pointer than pay the penalty of checking every pointer for validity?
  37.  
  38. Right!  That signal should be optional, not mandatory.  But, perhaps,
  39. the question of whether and when to issue a signal is viewed as a 
  40. quality-of-implementatino issue.  If so, then the implementation 
  41. already has all the leeway it needs without opening the door to 
  42. "undefined behavior."
  43.  
  44. Tom Payne (thp@cs.ucr.edu)
  45. ---
  46. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  47. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  48. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  49. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  50. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  51.